Along with rapid development of the Internet and popularization of large-screen multifunctional mobile phones, a great deal of mobile data multimedia services and various high-bandwidth multimedia services emerge, such as video conferencing, television broadcasting, video on demand, advertising, online education and interactive games. Increasing service requirements of mobile users are met on one hand, and on the other hand, new service increasing points are also brought to mobile operating companies. These mobile data multimedia services require multiple users to simultaneously receive the same data. Compared with ordinary data services, these services have the characteristics of large data volume, long duration, time delay sensitivity and the like.
In order to effectively utilize mobile network resources, the 3rd Generation Partnership Project (3GPP) proposes a Multimedia Broadcast Multicast Service (MBMS). The MBMS is a technology of transmitting data from one data source to multiple targets to implement sharing of a network (including a core network and an access network) resource and increase a utilization rate of the network resource (particularly an air interface resource). The MBMS defined by the 3GPP may not only implement pure-text and low-rate message multicast and broadcast but also implement high-speed multimedia service broadcast and multicast to provide rich video, audio and multimedia services, which undoubtedly conforms to a development tendency of mobile data in the future and provides a broader service prospect for development of 3rd Generation (3G).
In Long Term Evolution (LTE), an MBMS may adopt a multicast mode, called as a Multicast/Broadcast over Single Frequency Network (MBSFN) sending mode. The MBMS adopting the multicast mode is also called as an MBSFN service, and multiple cells may adopt the same modulation and coding scheme and send the same content by adopting the same physical resource. Multi-cell transmission of the MBMS has the following characteristics: 1) the MBMS is synchronously transmitted in an MBSFN area; 2) combination of MBMS transmission in multiple cells is supported; 3) a Multicast Traffic Channel (MTCH) and a Multicast Control Channel (MCCH) are mapped to a Multicast Channel (MCH) in a Point-to-Multipoint (p-T-m) mode; and 4) an MBSFN synchronization area, an MBSFN area, MBSFN transmission, advertisement and a preserved cell are all semi-statically configured by an Operation Administration and Maintenance (OAM). In such a manner, User Equipment (UE) of multiple cells may receive multiple pieces of MBMS data with the same content and perform Single Frequency Network (SFN) combination, thereby increasing a gain of a received signal. Multiple cells which send the same MBMS by adopting the same physical resource and an MBSFN sending mode form an MBSFN area.
During practical LTE networking, a plurality of MBSFN services exist in one MBSFN area and all of these MBSFN services belonging to the same MBSFN area form one MBSFN service group. In other words, one MBSFN service group belongs to only one MBSFN area. One MBSFN area includes multiple cells, and one and the same MBSFN service group is configured for each cell. Data channels MTCHs with multiple MBSFN services of the same MBSFN area and a control channel MCCH of the MBSFN services may be multiplexed to one MCH. An MCCH and multiple MTCHs of the same MBSFN area, i.e. multiple logical channels, may be mapped to the same transmission channel MCH.
An MCH is borne through a Transport Block (TB) of an MBSFN sub-frame.
In communication technologies, an MCH Sub-frame Allocation Pattern (MSAP) occasion is introduced into the concept of MSAP, and indicates all multicast resources included in one MCH corresponding a certain MSAP within a time period of a dynamic scheduling period. In one MSAP occasion, multiple MTCHs and dynamic scheduling information may be sent, and an MCCH may also be included. The dynamic scheduling information is borne in a Media Access Control (MAC) Protocol Data Unit (PDU) Control Element (CE), and a length of the MSAP occasion may be 320 ms. A time length of one MSAP occasion is one scheduling period, and is also called as one dynamic scheduling period. One or more MBSFN sub-frames in one or more MBSFN frames are allocated for one MCH through an MSAP, where a sub-frame sent in a multicast mode is called as an MBSFN sub-frame, and a frame including MBSFN sub-frames is called as an MBSFN frame.
On each MSAP occasion configured for one MCH, dynamic scheduling information is borne, and mapping information from MTCHs to auxiliary MSAP sub-frames is contained. The mapping information is determined by virtue of a number index relationship of MBSFN sub-frames in a scheduling period. UE may read the scheduling information to know allocation of each MTCH on the MBSFN sub-frames, and the UE may read an interested MTCH on the corresponding MBSFN sub-frames and neglect the MBSFN sub-frames not required to be read, so that MBMS receiving efficiency of the UE is improved, and power consumption of the UE is reduced. Here, numbers of the MBSFN sub-frames are determined as follows: all MBSFN sub-frames allocated for an MCH within one scheduling period are sequentially arranged and sequentially numbered.
In a related LTE technology, multiple logical channels multiplex the same MCH in a manner as follows. One sub-frame corresponds to one Transmission Time Interval (TTI), one TB may be sent in one TTI and each TB corresponds to one MAC PDU. One MAC PDU may include multiple MAC Service Data Units (SDUs), and these MAC SDUs may be from different logical channels, the logical channels probably including an MTCH, an MCCH and the like. Data from different logical channels is sent together on a physical channel after being connected in series in the MAC PDUs.
An MCH Scheduling Information (MSI) MAC CE is shown in FIG. 1. As shown in Table 1, a MAC PDU sub-header containing a Logical Channel Identifier (LCID) is adopted for identification. The MAC CE has a variable length, which is 2× bytes (where x is the number of elements in an MBMS-SessionInfoList sequence). Each MTCH includes the following fields:
LCID: this field indicates an LCID of the MTCH, and a length of the field is 5 bits; and
Stop MTCH: this field indicates a sequence number of a stop sub-frame of the corresponding MTCH in an MSAP occasion, and a length of the field is 11 bits. A specific Stop MTCH value 2047 indicates that the corresponding MTCH is not scheduled, and values ranging from 2043 to 2046 are reserved.
FIG. 1 is a schematic diagram of a dynamic scheduling information MAC CE according to a related technology. As shown in FIG. 1, when a certain MTCH in a MAC PDU is not sent, the stop MTCH is identified by 2047. Even when all MTCHs have no data, MSI is still sent. If the MSI is not sent (there is an MBMS service indicator in an MCCH), UE considers that a base station (e.g., an Evolved Node B (eNB)) has an error.
FIG. 2 is a schematic diagram of an MBMS trunking communication system according to the related technology. As shown in FIG. 2, the trunking communication system is a dedicated wireless communication system developed to meet a commanding and scheduling requirement of a user in the industry and oriented to a specific industrial application. A large number of wireless users share a small number of wireless channels in the system. The system takes commanding and scheduling as a main application, and is a multipurpose and high-performance wireless communication system. The trunking communication system has a broad application prospect in the fields of government departments, public security, emergency communication, power, civil aviation, petrochemical industry, military and the like. Trunking communication in 3GPP LTE is called as a Group Communication Service Enabler (GCSE).
The 3GPP decides to adopt an MBMS technology to implement public network LTE trunking communication, and makes further researches on Mission-Critical Push-To-Talk (MCPTT). At present, the 3GPP is discussing about how to ensure continuity of a trunking service in case of user plane data congestion of an MBMS. One solution is that an eNB notifies a Multi-cell/Multicast Coordination Entity (MCE) of occurrence of congestion or overload, the MCE selects to suspend the MBMS, and the eNB notifies influenced UE.
However, it is found in a researching and practising process of the related technology that the following problem exists: for how to notify an eNB by an MCE and how to notify influenced UEs by the eNB when the MCE receives congestion or overload indication information and selects to suspend an MBMS, there are yet no solutions.
For the problem of how to notify an eNB when a network element receives congestion or overload indication information and selects to suspend an MBMS in the related technology, there is yet no effective solution.